home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 2240 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.3 KB
  1. Path: hpcvsnz.cv.hp.com!news
  2. From: Brian Dixon <briand@cv.hp.com>
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Why use private class members instead of protected?
  5. Date: 16 Jan 1996 15:59:53 GMT
  6. Organization: Hewlett Packard Ink-Jet Business Unit
  7. Message-ID: <4dgi1p$m5l@hpcvsnz.cv.hp.com>
  8. References: <30F4AB49.6ABB@sierra.net> <30F50874.15FB7483@intellektik.informatik.th-darmstadt.de> <4dgd18$as0@mercury.wright.edu>
  9. NNTP-Posting-Host: hpcvibsd.cv.hp.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 1.1N (X11; I; HP-UX A.09.03 9000/747)
  14. X-URL: news:4dgd18$as0@mercury.wright.edu
  15.  
  16. >>> I'm relatively new to c++.  I have one quick question:  If child
  17. >>> classes can only access protected members of the parent class,
  18. >>> why make any members of any class private?  Wouldn't it be
  19. >>> better to make members of the parent class protected so that the
  20. >>> class is alway "inheritance ready"?
  21. >>No,
  22. >>it's quite often a better approach to make these data-members private and
  23. >>provide the suitable accessor functions. In this way you can change the
  24. >>representation of the data-members without the problem that modifications
  25. >>will 'propagate' downwards the class-hierarchy.
  26. >
  27. >I agree.  However, there are still instances when one would make a data
  28. >member protected.  In particular, very basic (as in linked list) classes
  29. >with a stable representation should have protected data members.  Why?  For
  30. >two reasons.
  31. >
  32. >    1.  Being basic classes, they (and their derived classes) are likely to
  33. >        be heavily used, especially in inner loops.  Even minor
  34. >        optimizations, such as eliminating copying for an accessor function
  35. >        would have benefits throughout your source code.
  36. >
  37. >    2.  Since they have a stable, efficient representation, and have been
  38. >        studied for years, the representation is unlikely to change and
  39. >        cause problems throughout the class hierarchy.
  40. >
  41.  
  42. I disagree.  If the data representation is that simple, then 'inline' the
  43. accessor function or define it within the class definition so it will be
  44. automatically inlined.  That will keep your "tried and true" algorithms
  45. the same and you don't pay a function call penalty.  But as you can tell
  46. from my answer, I do agree with using accessor functions to prevent down-
  47. propagation of data representation errors into derived classes.
  48.  
  49. Brian
  50.  
  51.